home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Feb 91 / MacApp.Tech$ 2⁄15⁄91 / 2953-Yet Another OP⁄C++ p-Feb91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.6 KB  |  61 lines  |  [TEXT/GEOL]

  1. Item    5343119                         13-Feb-91        16:56PST
  2.  
  3. From:   SNYDER                          Snyder, Seth
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    Yet Another OP/C++ plea
  10.  
  11. RE: Yet Another OP/C++
  12.  
  13. Hey Apple please don’t change to a C++ only world;
  14.  
  15. For all the reasons mentioned earlier and the ones listed below I think it will
  16. be a long time before I will be able to use a version of MacApp written in C++
  17. not that I really want to anyway.
  18.  
  19. 1. It has taken 5 years to get from version .1 of MacApp to version 2.0
  20. literally thousands of bugs have been removed in all the various versions that
  21. have been released and MacApp is now a very stable and robust development
  22. environment. There is no way anybody is going to rewrite MacApp in another
  23. language and have anything near as stable as it is now without going thru just
  24. as many releases and bug fixes etc. This will probably take about the same
  25. number of years to accomplish.  We are all in the business of producing
  26. reliable software. Why would a software developer subject themselves to these
  27. kinds of risks?
  28.  
  29. The only way Apple could possibly pull this off is if they had an OP to C++
  30. translator tool that could translate 100.00 % of MacApp's OP code to C++.  If
  31. the c++ code produced could compile and build a c++ version of MacApp that
  32. could be as stable as the OP code performs now.
  33.  
  34. By the way if Apple can produce a tool like the one described it would be
  35. fairly easy to keep versions of MacApp available in C++  as well as OP.  This
  36. tool and its companion a C++ to OP translator would alleviate many of the
  37. concerns that have been expressed if it were made available to us.
  38.  
  39. What will happen if MacApp 3.0 is only available in C++ or if the source code
  40. is not supplied with MacApp? People will surely keep on working with the last
  41. official release of MacApp. Probably all matter of bug repairs and updates will
  42. become available throughout the MacApp community. The MacApp community will
  43. adopt the responsibility for MacApp's future.
  44.  
  45. I hope that any object oriented development environments that become available
  46. from Apple in the future provide the source code for their object libraries. Or
  47. many developers will not want to use them and will probably find other class
  48. libraries to use that do. While looking for these new class libraries  most
  49. developers will probably choose to make a switch to one that provides a high
  50. level of cross platform independence. And as a byproduct of that switch Apple
  51. will no longer be one of the leaders in OOP.
  52.  
  53.  
  54.  
  55.  
  56. Sincerely
  57.  
  58.  
  59. Seth Snyder
  60.  
  61.